1. Field of the Invention
The present invention relates generally to designing and evaluating performance level models of electronic systems and amongst other things to a method and system for creating and simulating models of electronic systems at the system level.
2. Background of the Invention
In the traditional electronic system design process, behavior and architecture specification are followed by hardware and software design. The opportunity to consider tradeoffs in function and architecture performance occurs too late in the design flow for any changes to be made in either a timely or cost-effective manner.
The design process of the products for these systems is subject to a number of constraints. A first constraint is that they must be implemented in silicon or another hardware platform for power, performance and cost reasons. A second constraint is that these products implement systems conceived by a highly specialized system team thinking in terms of executable concurrent programming paradigms which, today, are not well understood by hardware designers. In fact, in most systems the partitioning of functions between hardware and software is based upon designer's past experience and is not subject to any analysis. Then, the partitioned specifications are translated into a specific hardware description language (HDL) such as Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL) or Verilog for the hardware components and a software description language such as C or assembler for the software components. Although the hardware and software have tight interaction, both hardware and software are designed separately. Only after the system is assembled is the software and hardware run together. As a consequence, the design can be far from optimal or even erroneous, making a redesign cycle mandatory.
This gap between system design and implementation is rapidly becoming the most problematic bottleneck in the design process of such products and systems. At the same time the conditions of the marketplace have created a need to quickly design products because of time to market requirements. Therefore, as the design time grows the time allowed for design in the business cycle continuously decreases. A major approach to shortening the design time is by attempting to implement hardware/software co-design procedures, so that the hardware and software of a system can be concurrently designed in order to speed up the design process. However, efficient co-design methodologies and approaches have not been easy to conceive or implement. One of the reasons for this is that the methodologies for hardware design and software design have their own approaches that are difficult to mesh.
Several approaches have been attempted to create a true co-design methodology. One known approach is a co-verification approach, where designed hardware and software are verified together utilizing a co-verification simulator. A problem with this approach is that all the hardware must be built and designed to the cycle accurate level at this point, and therefore any problems that arise during co-verification, if they can be addressed by redesigning the hardware, are difficult to implement as the hardware has already been designed and implemented. Similarly, the software for the system needs to be compiled prior to co-verification.
Another approach to co-design is by instruction set (ISS) co-simulation. This approach concurrently simulates the instruction sets for a processor and related components by utilizing an HDL description of the system and a model of the instruction set. While this can lead to an effective co-simulation, this approach still utilizes a model of the hardware that is functionally complete making it difficult to replace or substantially redesign any hardware components. This approach also requires a complicated processor model which is difficult to create and thus provides a high barrier to exploration of various processors. This approach too results in hardware over-design, with the related higher costs, power consumption, and equipment sizes in systems.
Therefore, there is a need for a hardware/software co-design methodology that allows for simulation at a level where the hardware is not yet completely designed, to allow simple redesign of the hardware components.
Another issue in the design of digital systems is the ability to reuse components that were used in previously designed systems. The design process for a digital system must allow for the reuse of components, and therefore support a reusable design methodology. The problem in reusing previously designed components lies in the fixed communication protocols they use, which necessitates protocol conversions when different components with different protocols have to be interfaced. In fact, it has been noted that more than half of all designs are reused in building future systems.
Today, the selection of a protocol is done while designing the component: functional and communication behavior are intrinsically mixed. However, a good selection of the protocol is possible only when all components involved in the communication are known. Therefore, a design environment for digital systems should permit a component to be initially described in purely functional terms. Later, when the component is (re)used in a system, the design environment must allow to plug in the most appropriate communication behavior. This approach is in contrast with current hardware design practices, where communication and functional behavior are mixed.
The ability to reuse components requires component modularity. In modular designs, the complete system functionality is split into communicating components of manageable complexity. The advantage of this approach is that the components can be reused and that the system is easier to adapt and maintain.
Additionally, the following requirements should be considered for a hardware/software system design environment. (1) modularity is essential to reduce complexity; (2) multiple description languages should be accommodated to allow each system component to be described within the most appropriate paradigm; (3) the design environment must be able to model the heterogeneous conceptual specification, the resulting heterogeneous architecture and all refinement steps in between; and (4) off-the-shelf components and the associated design environments should be modeled.